IBIS Macromodel Task Group Meeting date: 3 March 2020 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva ANSYS: Dan Dvorscak Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Justin Butterfield took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 25 meeting. Bob moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- DDR clock forwarding BIRD draft: Fangyi looked at every instance of GetWave in the current IBIS 7.0 specification. He added paragraphs to the last page of the BIRD about the differences between GetWave and GetWave2. The rules are the same, but there are three exceptions noted in the BIRD. Fangyi suggested this should cover all the references in the current specification. Bob asked if this version of the BIRD was sent out to the ATM group. Fangyi replied it was. Michael clarified if an earlier version was posted. Fangyi replied it is the same, but it did not include these last three paragraphs. Randy asked if this requires a specific flow with separate DLLs for DQ and DQS. Fangyi responded there are no restrictions on this. Randy asked if this means tools will require different flows. Fangyi noted the current AMI flow should still apply. The exception is when the GetWave2 has to apply the wave_clk argument. Randy asked if this will cause issues across different tools. Walter thought this could be an issue for model makers, as it adds complexity. He would like to see this implemented in models. Michael commented it would be nice to have a diagram and a flow chart. Walter noted there are pictures in Fangyi's presentation. Michael commented the issue of when multiple DLLs vs. multiple functions should be used was not clear in these diagrams. Arpad noted a pass-through DLL for the DQS might be necessary. He asked if this should be made a requirement. Randy stated his first thought is to have the DQS functionality in one DLL with the DQ. Fangyi noted, if you put the functionality in the DQS DLL, then you don't need to duplicate the functionality in the DQ DLL for each DQ. Randy asked if there would be any issues with waveform alignment between DQS and DQ and the passing of data to the DQ Rx model. Walter replied, if you have a CTLE in the DQS, there could be some delay in the model and there can be left over data. This delay will need to handled in the DQ. His thought is it would be easier to put the DQS and DQ in the same to DLL to make sure they work together. The problem is you need to know which edge from the DQS goes with the DQ data. Fangyi stated the DQ can detect the edge. Randy commented the simulator may have to do some alignment simulation in either case. Arpad asked if the model maker will need to do something, and how should the alignment would be carried out. He asked if we need a parameter in the DQ to output the timing alignment. Randy commented in the hardware this is done with the write-leveling. Fangyi suggested the simulator will have to do the write-leveling. Walter stated the skew between the DQ and DQS can cause the edges to become uncorrelated. It is still an open issue how to analyze these systems. He would like to see what the IC vendors come up with and if there are simpler solutions that can model this effect. We need to know if this is a problem that needs solved. Fangyi noted he has at least one customer asking for this. DDR5 Write Protocol: Walter added the ability for the Tx to tell the Rx what the Vref should be. The other change is to have the Tx tell the Rx the DFE voltage coefficients. The Rx can output the voltage values of the DFE tap values. He noted both methods of reporting the DFE tap values may or may not be necessary to include in the protocol. Bob asked, about the parameters on slide 4, if these are reserved parameters or model specific parameters. Walter noted these are the strings read by the Tx and Rx models for the back-channel protocol. These have nothing to do with the IBIS standard, but this is an agreement between the Rx and Tx model writers. He chose to follow the parameter tree format, since model makers can parse it. The EDA tool could read this file, but it is not required. Michael asked about the tap values in register integer or coefficient format and if the model can flag a preferred way of specifying the parameters. Walter replied, since the Tx is driving, the Rx should be able to handle either. He would recommend to have the Rx be a slave to the Tx. Discussion on “Gap in IBIS for sampling with statistical mode AMI models”: Arpad asked if we have any action on creating a BIRD for this. Walter stated he preferred to not write this one. He suggested to have Hansel write the BIRD. Arpad noted he had mistakenly thought Walter would write the BIRD. Walter will contact Hansel to ask him to write the BIRD. AR: Walter to send out the DDR5 DQ Write Protocol presentation. AR: Fangyi to send out the latest GetWave2 API BIRD draft. AR: Walter to ask Hansel to draft a BIRD to address the AMI statistical sampling point issue. - Randy: Motion to adjourn. - Michael: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 10 March 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives